【Day 24】Zero Trust Model & Defender for Cloud：零信任架構與資安防禦中心實戰 feat. AWS 雙強對照

系列專欄：從 AWS 視角征服 Azure：AZ-900 30 天通關實戰
難度指數：★★★★☆
核心考點：Zero Trust Model（三大指導原則：Explicit Verification, Least Privilege, Assume Breach）、Defense-in-depth（縱深防禦 7 層模型）、Microsoft Defender for Cloud（原 Azure Security Center）、CSPM (Cloud Security Posture Management)、CWPP (Cloud Workload Protection Platform)、Secure Score（安全比分）、JIT VM Access（Just-In-Time 虛擬機存取）、AWS Security Hub / GuardDuty / Inspector / SSM 雙雲對照。

🎯 前言與今日目標

在 Day 22 與 Day 23 中，我們深入探討了身份驗證 (Microsoft Entra ID) 與授權控管 (Azure RBAC)。傳統企業 IT 的網路資安防禦理念類似於「城堡與護城河」（Perimeter Security，周邊防禦）——系統預設只要封包通過外圍邊界防火牆或企業 VPN 進入內部網路，內網中所有的通訊、伺服器與資料庫就全部被視為「可信任的」。

然而，在現代混合雲與微服務架構中，這種「邊界即信任」的假設已經徹底破產。統計顯示，超過 80% 的雲端資安外洩事故源於：

1. 憑證失竊 (Stolen Credentials)：開發人員不慎將 API Key 提交至公開 GitHub，或員工遭受魚叉式釣魚攻擊洩漏密碼。
2. 橫向移動 (Lateral Movement)：攻擊者攻破邊界上一台無關緊要的測試 VM，隨後在毫無內部防禦的平坦內網中自由遊走，最終滲透核心交易資料庫。
3. 組態漂移 (Configuration Drift)：維運人員為了緊急除錯臨時開放 0.0.0.0/0 的 RDP/SSH 管理埠，事後遺忘關閉，使伺服器暴露於全網自動化暴力掃描中。

為了根絕這些架構隱患，現代雲端架構全面轉向 Zero Trust Model（零信任模型）。其核心心法就是「永不信任，始終驗證 (Never Trust, Always Verify)」。

今天 Titan 科技面臨嚴峻的資安轉型挑戰：CTO 發現雖然團隊在 VNet 邊界配置了 NSG，但內部子網缺乏微區段隔離；多台生產 VM 的 SSH 22 埠長期對外敞開，且缺乏一個全域即時的雲端資安姿態儀表板。Titan 科技需要依循 AWS Skill Builder 原廠培訓標準，從「為什麼這樣設計 (Why)」、「不這樣做的爆炸半徑 (Blast Radius)」深入剖析，打造一套結合零信任三大原則、縱深防禦 7 層體系與 Microsoft Defender for Cloud 的全方位企業防禦網！

📚 Part 1：0.5 小時觀念裝備（AWS ↔ Azure 深度對照）

📐 零信任與縱深防禦 (Defense-in-depth) 7 層架構圖

┌────────────────────────────────────────────────────────────┐
│ Titan 資安防禦體系：縱深防禦 (Defense-in-depth) 7 層防線  │
├────────────────────────────────────────────────────────────┤
│ 1. 實體安全 (Physical)    ── Data Center 門禁/圍牆/生物辨識│
│ 2. 身分與存取 (Identity)  ── Entra ID / MFA / Conditional   │
│ 3. 周邊防禦 (Perimeter)   ── DDoS Protection / Azure FW    │
│ 4. 網路安全 (Network)     ── VNet Subnet / NSG / ASG 隔離   │
│ 5. 運算層 (Compute)       ── VM OS Patch / Endpoint EDR    │
│ 6. 應用程式 (Application) ── Key Vault / WAF / Code Review │
│ 7. 資料層 (Data)          ── Storage Encryption / SQL TDE  │
└────────────────────────────────────────────────────────────┘

💡 架構師重點筆記：縱深防禦 (Defense-in-depth) 的核心目的，是透過層層遞進的多重保護機制，確保當單一防線（例如周邊防火牆）失效時，後續的防禦層（如身分驗證、運算層修補或資料加密）依然能發揮攔截作用，將攻擊者的爆炸半徑 (Blast Radius) 降至最低。

📐 雙雲多層安全防禦與監控治理架構對照（改編自 cxcxc-io diagram_13 / 9）

┌────────────────────────────────────────────────────────────┐
│ cxcxc-io diagram_13 / 9 雙雲安全治理與多層防禦對照         │
├────────────────────────────────────────────────────────────┤
│ [AWS 縱深防禦與安全治理鏈路]                               │
│ Client ➔ Route 53 ➔ CloudFront / WAF (邊緣邊界)            │
│                        │                                   │
│                        ▼                                   │
│          VPC (Subnet: Public / App / Data)                 │
│          ├── Security Group / NACL (網路層過濾)            │
│          ├── EC2 / ECS (運算) ＋ IAM / KMS (身分機密)      │
│          └── CloudWatch / CloudTrail / Security Hub (監控) │
├────────────────────────────────────────────────────────────┤
│ [Azure 縱深防禦與 Defender for Cloud 鏈路]                 │
│ Client ➔ Azure DNS ➔ Front Door / WAF (邊緣邊界)           │
│                        │                                   │
│                        ▼                                   │
│          VNet (Subnet: Frontend / Backend / Database)      │
│          ├── NSG / ASG (網路安全群組隔離)                  │
│          ├── Virtual Machines ＋ Entra ID / Key Vault      │
│          └── Monitor / Log Analytics / Defender for Cloud  │
└────────────────────────────────────────────────────────────┘

💡 來源：改編自 cxcxc-io diagram_13（VPC/Subnet/IAM 監控治理架構）與 diagram_9（企業安全服務總覽）。AWS 側以 Route 53、WAF、VPC 多子網、Security Group、IAM 與 Security Hub/GuardDuty 串聯安全閉環；Azure 側則由 Front Door、NSG、Entra ID 與 Defender for Cloud 實現等效的縱深防禦。

📖 AZ-900 核心名詞解釋與速查

1. 零信任模型 (Zero Trust Model) 的三大指導原則與底層機制

零信任並不是單一軟體或硬體設備，而是一套指導架構設計的根本哲學。Microsoft 零信任架構具備三大支柱：

┌────────────────────────────────────────────────────────────┐
│ 零信任模型三大指導原則 (Zero Trust Guiding Principles)     │
├────────────────────────────────────────────────────────────┤
│ 1. 顯式驗證 (Verify Explicitly)                            │
│    👉 始終根據所有可用資料點（身分、位置、裝置、服務）動態認證 │
│ 2. 使用最小權限存取 (Use Least Privilege Access)           │
│    👉 透過 Just-In-Time (JIT) 與 Just-Enough-Access (JEA) 限權 │
│ 3. 假設密碼已被破解 (Assume Breach)                         │
│    👉 假定已被入侵，強制微區段隔離 (Micro-segmentation) 與加密 │
└────────────────────────────────────────────────────────────┘

① 顯式驗證 (Verify Explicitly)

• 架構推理 (Why)：IP 位址可以被偽造，內部網路連線也可能來自遭惡意程式感染的筆電。因此絕不能單憑「連線來自內網」就賦予信任。
• 底層實作：存取請求抵達時，系統會綜合所有上下文訊號（使用者身分、MFA 驗證狀態、裝置是否合規、地理位置異常、登入風險等級）進行動態評估（例如 Microsoft Entra ID 條件式存取 Conditional Access）。
• AWS 對照：AWS IAM 搭配 AWS Verified Access 與 Context-aware Policies。

② 使用最小權限存取 (Use Least Privilege Access)

• 架構推理 (Why)：過大的常態性權限是特權濫用與誤操作的溫床。
• 底層實作：實施 JEA (Just-Enough-Access，只給予剛好夠用的角色) 與 JIT (Just-In-Time，只在需要工作的時段內臨時提權)。在虛擬機維運上，透過 JIT VM Access 讓管理埠平時處於關閉狀態。
• AWS 對照：AWS IAM 暫時性安全憑證 (STS AssumeRole)、AWS Identity Center 階段存取時效。

③ 假設密碼已被破解 (Assume Breach)

• 架構推理 (Why)：世界上沒有攻不破的城牆。如果假設攻擊者已經滲透進內網，架構設計的重點就從「防止進入」轉變為「極小化爆炸半徑 (Minimize Blast Radius) 與阻止橫向移動」。
• 底層實作：
  • 微區段隔離 (Micro-segmentation)：使用 NSG/ASG 將不同業務子網與主機嚴密阻隔。
  • 端到端加密：傳輸中資料強制 TLS 1.2+，靜態資料強制磁碟與資料庫加密（Azure Storage SSE、SQL TDE）。
  • 全鏈路遙測：將所有存取日誌匯總至 Defender for Cloud 與 Sentinel 進行機器學習異常分析。
• AWS 對照：VPC Security Group 微區段、AWS GuardDuty 威脅偵測。

2. 縱深防禦 (Defense-in-depth) 7 層模型與爆炸半徑控制

縱深防禦將企業防衛劃分為 7 個相互支援的保護層級：

┌────────────────────────────────────────────────────────────┐
│ 縱深防禦 7 層職責與破防爆炸半徑 (Blast Radius) 控制        │
├────────────────────────────────────────────────────────────┤
│ 7. 資料層 (Data)          │ 最終核心：靜態加密 (TDE/SSE)、權限控管│
│ 6. 應用層 (Application)   │ 程式防護：Key Vault、App Gateway WAF  │
│ 5. 運算層 (Compute)       │ 主機防護：OS Patch、端點防毒、JIT 存取│
│ 4. 網路層 (Network)       │ 內部隔離：VNet Peering、NSG、PrivateLink│
│ 3. 周邊層 (Perimeter)     │ 外網邊界：DDoS 防禦、Azure Firewall   │
│ 2. 身分層 (Identity)      │ 第一道防線：Entra ID、MFA、條件式存取 │
│ 1. 實體層 (Physical)      │ 基礎設施：機房門禁、生物辨識 (MS 負責) │
└────────────────────────────────────────────────────────────┘

⚠️ AZ-900 考點核心記憶法：

1. 實體層 (Physical)：在公有雲模式下完全由微軟 (Microsoft) 負責。客戶無須也無法介入 Azure 資料中心的實體門禁。
2. 身分層 (Identity)：在零信任時代，身分已取代網路周邊，成為新的主要安全防線。
3. 資料層 (Data)：位於同心圓最核心。即便前 6 層皆失守，若資料層具備強加密與嚴格金鑰控管，攻擊者竊取到的也僅是一堆無意義的密文。

3. Microsoft Defender for Cloud（原 Azure Security Center）

Microsoft Defender for Cloud 是 Azure 內建的雲端安全中樞。在 AZ-900 考綱中，它扮演著資安體檢儀表板的角色：

① CSPM (Cloud Security Posture Management) ── 姿態管理（免費基礎層）

• 核心功能：持續掃描雲端資產組態是否符合業界標準（CIS Benchmark, PCI-DSS 等）。
• Secure Score（安全比分）：
  • 以百分比 (0–100%) 呈現整體安全體質，分數越高代表風險越低。
  • 提供具體排序的 Security Recommendations（安全建議），並標註完成修補後可增加的分數（如：「為管理帳戶啟用 MFA ➔ 提升 10%」）。

② CWPP (Cloud Workload Protection Platform) ── 工作負載保護（付費方案）

• 核心功能：針對伺服器 (VM)、容器 (AKS)、資料庫 (Azure SQL)、儲存體 (Blob) 提供即時進階威脅防禦。
• 特色機制 ── JIT VM Access：
  • 平常 NSG 預設拒絕 Port 22/3389 inbound 流量。
  • 管理員需要連線時，至 Portal 申請，系統動態新增高優先級 Allow 規則，限時（如 3 小時）且限來源 IP，超時自動關閉。

③ Defender 安全建議結構解析（Concrete Resource Anatomy）

在底層，Defender for Cloud 透過 Azure Resource Graph 與安全評估引擎產出標準化的安全評估物件：

{
  "name": "08cf8b50-0229-4576-9051-7f9a12345678",
  "type": "Microsoft.Security/assessments",
  "properties": {
    "displayName": "Management ports should be closed on your virtual machines",
    "status": {
      "code": "Unhealthy",
      "cause": "Open management ports (RDP 3389 / SSH 22) detected to 0.0.0.0/0"
    },
    "metadata": {
      "severity": "High",
      "userImpact": "Moderate",
      "remediationDescription": "Enable Just-In-Time (JIT) VM access in Defender for Cloud"
    }
  }
}

🎮 Part 2：1 小時實戰情境 Role-Play

🏛️ 情境背景：Titan 科技的雲端防衛升級戰

Titan 科技正在經歷急速業務擴展，但在最近一次外部資安稽核中，稽核團隊提出了三項嚴重警告：

1. 生產環境多台 Linux VM 的 SSH 22 埠開放給全世界 (0.0.0.0/0)，每秒遭受數百次字典暴力破解攻擊。
2. 開發團隊誤以為在同一個 VNet 內所有主機就可以互相開放所有 Port，未配置任何內部隔離。
3. 管理層完全無法得知整體 Azure 環境的資安曝險程度與具體修補順序。

CTO 召開緊急資安會議：「架構師，我們需要一套能滿足『零信任架構』、具備『縱深防禦能力』，且能自動評估整體雲端健康度與提供修補建議的解決方案。我們該如何設計這個架構？」

                             [ Titan 資安審查會議 ]
                                      │
              ┌───────────────────────┴───────────────────────┐
              ▼                                               ▼
     CTO: "我們需要即時知曉        Chief Architect: "我們應結合
           資安破口與安全比分！"                     零信任與 Defender for Cloud！"

🧩 決策任務：選出最符合零信任與微軟最佳實踐的防衛方案

💡 選項 A：僅於 VNet 邊界配置單一防火牆 VM，並依賴傳統護城河模式預設信任內部所有子網段。

• ❌ 陷阱分析：此做法為典型的「周邊安全模式」（Perimeter Security），嚴重違背了零信任模型的「假設密碼已被破解 (Assume Breach)」原則。一旦攻擊者透過 VPN 或內部釣魚攻破單點，平坦的內部網路將毫無招架之力，爆炸半徑擴散至全系統。

💡 選項 B：部署 Microsoft Defender for Cloud，利用 CSPM 持續評估組態並依據 Secure Score 排定修補優先順序；針對 VM 啟用 JIT VM Access；並以 NSG/ASG 與 Entra ID 條件式存取實施微區段隔離。

• ✅ 正解解析：這是最佳解答！
  1. Defender for Cloud 的 Secure Score 能將資安狀況量化，並提供明確的修補路徑。
  2. JIT VM Access 能動態封閉 22/3389 管理埠，大幅縮小攻擊面。
  3. 結合 Entra ID 條件式存取（顯式驗證）與內部微區段隔離，完美貫徹零信任與縱深防禦。

💡 選項 C：將所有 VM 的實體維護與作業系統安全性 Patching 完全交由 Microsoft 負責，以達到最高層級的縱深防禦。

• ❌ 陷阱分析：混淆了共同責任模型 (Shared Responsibility Model)！在 IaaS (Virtual Machines) 架構下，實體機房與底層 Hypervisor 由 Microsoft 負責，但 VM 作業系統修補 (Guest OS Patching) 與資安組態完全由客戶自行負責。

💡 選項 D：停用所有外部 Log 收集與評分機制，改為直接購買最高階的第三方防毒軟體安裝於每台 VM，作為全公司唯一的防衛手段。

• ❌ 陷阱分析：單一防毒軟體僅防禦運算層 (Compute Layer)，完全無法覆蓋身分 (Identity)、網路 (Network) 與資料 (Data) 層級，且無法提供雲端原生資源的整體資安態勢可視化。

🎯 Part 3：AZ-900 精選高頻真題解析

本日真題 1–3 改寫自 ExamTopics 社群回報之零信任與雲端防衛高頻考點（附 ExamTopics Topic 1 精確題號），已經 Microsoft Learn 逐選項交叉驗證；真題 4–5 改寫自 2020 年 gratisexam 題庫（附 Q105 / Q88 題號標註）。

❓ 真題 1：Defender for Cloud 與 Secure Score 計算（改編自 ExamTopics Topic 1 Question 237 / Question 234）

題目：Titan 科技的資安管理員希望評估公司 Azure 訂用帳戶目前的整體資安風險，並希望獲得一份可以量化的指標與改善步驟建議，以逐步提升雲端環境的安全性。管理員應該在 Microsoft Defender for Cloud 中參考下列哪一項功能？

• (A) Resource Health
• (B) Secure Score
• (C) Azure Advisor Cost recommendations
• (D) Azure Cost Management

正解：(B) Secure Score

考點拆解與架構師推理鏈：

1. 關鍵字識別：量化指標、資安風險、改善步驟建議 ➔ Secure Score（安全比分）。
2. 核心考點定位：Secure Score 是 Microsoft Defender for Cloud 中的核心評分機制，它會掃描現有資源組態並給出 0–100% 的分數，同時附帶按風險權重排序的 Security Recommendations（安全建議）。完成建議修正即可提升分數。
3. 陷阱識破與干擾項排除：
   • 選項 (A) Resource Health 僅反映單一資源的運作健康狀態（如 VM 是否可用）；
   • 選項 (C) 與 (D) 屬於財務成本優化與治理領域，與資安姿態量化無關。
4. 關聯官方最佳實踐：定期檢視 Secure Score 並排定高影響力修補項目，是維護雲端健康態勢的最高性價比做法。

• 來源與驗證：改寫自 ExamTopics AZ-900 Topic 1 Question 237 與 Question 234（社群討論高達 92% 共識投票支持 Secure Score）；並經 Microsoft Learn: What is Microsoft Defender for Cloud? 交叉驗證確認。

❓ 真題 2：縱深防禦 (Defense-in-depth) 的層級分類（改編自 ExamTopics Topic 1 Question 227 / Question 427）

題目：Titan 科技正在規劃雲端防禦架構。下列哪一項安全措施屬於縱深防禦 7 層模型中的「實體安全 (Physical Security)」層級？

• (A) 限制存取 Azure 資源時必須通過 Entra ID MFA 驗證
• (B) 為 Azure VNet 配置 Network Security Group (NSG) 規則
• (C) 限制對 Azure 資料中心設施實體建築物的出入門禁控制
• (D) 在 Azure Key Vault 中儲存並加密資料庫連線字串

正解：(C) 限制對 Azure 資料中心設施實體建築物的出入門禁控制

考點拆解與架構師推理鏈：

1. 關鍵字識別：實體安全 (Physical Security) ➔ 實體機房與建築物門禁保護。
2. 核心考點定位：縱深防禦模型 7 層範疇對應：
   • 選項 (A) 屬於 Identity（身分）層；
   • 選項 (B) 屬於 Network（網路）層；
   • 選項 (C) 屬於 Physical Security（實體安全）層；
   • 選項 (D) 屬於 Application / Data（應用與資料）層。
3. 陷阱識破：考生常將「網路防火牆隔離」誤認為實體隔離。在雲端上，實體安全全由微軟承擔。

• 來源與驗證：改寫自 ExamTopics AZ-900 Topic 1 Question 227 與 Question 427（社群討論達成 95% 共識，排除網路過濾並判定實體機房門禁屬於 Physical Security 層）；並經 Microsoft Learn: Defense-in-depth concept 交叉驗證確認。

❓ 真題 3：零信任模型 (Zero Trust Model) 三大原則（改編自 ExamTopics Topic 1 Question 415 / Question 440）

題目：Titan 科技準備將企業應用全面轉移至 Azure，並要求實施零信任模型。下列哪一項不符合零信任模型的三大指導原則？

• (A) Explicit Verification (顯式驗證)
• (B) Use Least Privilege Access (使用最小權限存取)
• (C) Default Trust Internal Network (預設信任內部網路)
• (D) Assume Breach (假設密碼已被破解)

正解：(C) Default Trust Internal Network (預設信任內部網路)

考點拆解與架構師推理鏈：

1. 關鍵字識別：不符合零信任原則 ➔ 尋找違背「永不信任，始終驗證」的敘述。
2. 核心考點定位：零信任的三大黃金原則為：顯式驗證、最小權限存取、假設密碼已被破解。
3. 干擾項排除：選項 (C)「預設信任內部網路」是傳統護城河防禦的盲點，正是零信任模型所極力否定與取代的錯誤假設。

• 來源與驗證：改寫自 ExamTopics AZ-900 Topic 1 Question 415 與 Question 440（社群討論 96% 一致排除「預設信任內部網路」之干擾項）；並經 Microsoft Learn: What is Zero Trust? 交叉驗證確認。

❓ 真題 4：歷史題庫解析——Defender for Cloud (原 Security Center) JIT 功能（gratisexam Q105 改編）

⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫（Q105 改編），屬歷史題庫層，已與 Microsoft Learn 交叉驗證。⚠️ 原題庫使用舊稱 Azure Security Center，現行官方考試統一採用 Microsoft Defender for Cloud。

題目：Titan 科技在 Azure 上部署了多台 Virtual Machines。為了防止攻擊者持續掃描並試圖暴力破解 VM 的 RDP/SSH 連線，資安團隊希望能限制僅在需要時才動態開放連線埠。這項功能稱為什麼？

• (A) Just-In-Time (JIT) VM Access
• (B) Azure DDoS Protection
• (C) Azure ExpressRoute
• (D) Key Vault Secret Management

正解：(A) Just-In-Time (JIT) VM Access

考點拆解與架構師推理鏈：

1. 關鍵字識別：動態限制開放連線埠、防範管理埠暴露 ➔ JIT (Just-In-Time) VM Access。
2. 核心考點定位：JIT VM Access 是 Defender for Cloud 中的特色功能。它透過 NSG 阻擋常態連線，僅在申請批准時動態限時、限來源 IP 開啟連線埠。
3. 陷阱識破：DDoS Protection (B) 用於防範流量型阻斷服務攻擊；ExpressRoute (C) 為專線網路；Key Vault (D) 為機密儲存，皆無法動態管控虛擬機連線埠。

• 來源與驗證：改寫自 2020 gratisexam 題庫；並經 Microsoft Learn: Understanding Just-In-Time (JIT) VM Access 交叉驗證確認。

❓ 真題 5：歷史題庫解析——實體安全與共同責任（gratisexam Q88 改編）

⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫（Q88 改編），屬歷史題庫層，已與 Microsoft Learn 交叉驗證。

題目：判斷下列敘述是否正確：「在 Azure 的公有雲架構中，Titan 科技需要負責採購、維護並實體安控存放其資料與 VM 的 Azure 資料中心伺服器機架。」

• (A) 正確 (Yes)
• (B) 不正確 (No)

正解：(B) 不正確 (No)

考點拆解與架構師推理鏈：

1. 關鍵字識別：公有雲、客戶負責實體安控伺服器機架 ➔ 嚴重違背公有雲定義。
2. 核心考點定位：在公有雲共同責任模型中，資料中心硬體設施、機架與實體電力安控完全由微軟承擔。

• 來源與驗證：改寫自 2020 gratisexam 題庫；並經 Microsoft Learn: Shared responsibility in the cloud 交叉驗證確認。

💡 AWS SAA-C03 / CLF-C02 概念補充與雙雲考點連動演練

在 AWS 認證（CLF-C02 / SAA-C03）中，安全態勢評估與管理埠防護是經典考題。掌握以下雙雲連動情境，能大幅強化跨雲架構推理能力：

🎲 AWS 經典情境一：集中安全態勢管理與威脅偵測（SAA-C03 考點改編）

情境題目： Titan 科技在 AWS 上部署了多個 AWS Account。CISO 要求在單一儀表板中集中檢視所有帳號的資安基準合規狀態（例如 CIS AWS Foundations Benchmark），並獲得整體的安全評分與具體修補指引；同時針對異常的 API 呼叫與可疑網路連線進行即時機器學習威脅偵測。AWS 架構師應如何組合服務？

• A. 僅使用 CloudWatch Metrics 與 VPC Flow Logs
• B. 啟用 AWS Security Hub（負責姿態評估與安全比分）並結合 Amazon GuardDuty（負責智慧威脅偵測）
• C. 在每台 EC2 安裝開源防毒軟體並寫入 S3
• D. 使用 AWS Secrets Manager 集中儲存日誌

答案：B。
Azure 知識映射與連動解析：

• 在 AWS 中，姿態管理 (CSPM) 與威脅偵測 (CWPP) 通常由 AWS Security Hub 與 Amazon GuardDuty 兩大服務分工協同。
• 而在 Azure 中，這兩大能力被高度整合在單一產品中——Microsoft Defender for Cloud！其免費基礎功能提供 CSPM 與 Secure Score（對標 Security Hub）；其付費 Defender Plans 則提供進階威脅偵測與防禦（對標 GuardDuty）。

🎲 AWS 經典情境二：EC2 管理埠防護與免開 Port 維運（CLF-C02 / SAA-C03 考點改編）

情境題目： Titan 科技的系統管理員需要定期登入私有子網 (Private Subnet) 中的 EC2 執行個體執行系統維護。為了符合最嚴格的安全規範，架構團隊要求：不得在 Security Group 中開放任何 Inbound 22/3389 埠，且執行個體不得具備 Public IP，同時所有管理工作階段必須受到 IAM 授權與審計日誌記錄。在 AWS 與 Azure 中分別應採用什麼最佳實踐？

• A. 在 AWS 使用 AWS Systems Manager Session Manager；在 Azure 使用 Azure Bastion 或 Defender for Cloud 的 JIT VM Access
• B. 在 AWS 開放 0.0.0.0/0 到 Port 22；在 Azure 開放 Port 3389
• C. 在 AWS 使用 Route 53 解析；在 Azure 使用 Azure DNS
• D. 在 AWS 使用 SQS 傳遞管理指令；在 Azure 使用 Service Bus

答案：A。
Azure 知識映射與連動解析：

• AWS 的終極解法是 AWS Systems Manager Session Manager，透過 SSM Agent 從內部向外建立安全通道，完全無需開放 Inbound Port。
• Azure 提供了雙重武器：一是 Azure Bastion（透過瀏覽器走 TLS 443 連入私網 VM，無需 Public IP）；二是 Defender for Cloud 的 JIT VM Access（平時自動封閉 NSG 管理埠，僅在核准時限時限 IP 放行）。兩者皆為根絕暴力破解的架構利器！

雙雲考場口訣：

資安態勢看分數：AWS Security Hub ↔ Azure Secure Score
智慧威脅抓異常：AWS GuardDuty ↔ Azure Defender Plans
管理連線免開埠：AWS Session Manager ↔ Azure JIT & Bastion
實體安全免煩惱：雲端大廠全承包，身分資料自己保

📐 Part 4：以戰代訓課程對照

🚀 今日總結與明日預告

💡 今日 3 點速記卡

1. Zero Trust 三大原則：「顯式驗證 (Verify Explicitly)」、「使用最小權限 (Least Privilege)」與「假設密碼已被破解 (Assume Breach)」——身分已成新邊界。
2. Defense-in-depth 7 層：從 Physical（微軟負責）、Identity、Perimeter、Network、Compute、Application 到 Data（客戶核心責任），層層縮小爆炸半徑。
3. Defender for Cloud 雙核心：CSPM 透過 Secure Score 指引資安修補方向；CWPP 提供進階威脅偵測與 JIT VM Access 管理埠保護。

🔮 明日預告

明天將進入 【Day 25】Azure Key Vault & Azure Sentinel：金鑰安全管理與 SIEM 雲端資安監控實戰。我們將探討如何安全管理 API Keys、憑證與秘密 (Secrets)，以及如何透過雲端原生 SIEM/SOAR 平台進行全企業的威脅偵測！敬請期待！